The SCEF is the 3GPP platform that enables IoT application servers to monitor IoT device state. The procedure for monitoring IoT devices is referred to as the 3GPP MTC monitoring event procedure and allows an IoT application server (AS) or service capability server/application server (SCS/AS) to monitor IoT device status and is described in 3GPP TS 23.682, Technical Specification Group Services and System Aspects; Architecture enhancements to communications with packet data networks and applications (Release 16), V16.2.0 (March 2019). The interface that an SCS or AS uses to invoke the 3GPP MTC monitoring event procedure is referred to as the T8 interface, which is specified in 3GPP TS 29.122, Technical Specification Group Core Network and Terminals; T8 reference point for Northbound APIs; (Release 16) V16.1.0 (March 2019).). The T8 interface is provided by the SCEF.
According to the 3GPP MTC monitoring event procedure, the IoT AS or SCS/AS sends a monitoring configuration (subscription) request to the SCEF over the T8 interface to monitor the required device parameter. The IoT AS can request continuous or one-time reporting of device status in the T8 monitoring configuration request to SCEF. The SCEF creates a monitoring context for a given monitoring configuration (subscription) request and assists in delivering the requested IoT device status. The SCEF retrieves the required device status information from EPC core network elements, such as the home subscriber server (HSS), mobility management entity (MME), or policy and charging rules function (PCRF), and generates device status reports towards the IoT AS. The MTC monitoring event procedure supports monitoring of IoT device status information (i.e., monitoring events), such as location information, roaming status, device reachability, connectivity status, communication failure, etc., from IoT AS through EPC network elements, such as the HSS, MME and PCRF.
FIG. 1 is a call flow diagram illustrating the 3GPP monitoring event procedure through the HSS using the northbound T8 interface. In FIG. 1, an SCEF 100 receives monitoring event subscription requests from an SCS/AS 102 and communications with an HSS 104 to obtain the requested IoT device state information. The monitoring of devices through the HSS using the T8 interface consists of two phases:
Configuration Phase:
                1) SCS/AS 102 sends a monitoring subscription request containing a monitoring event, such as location info, UE reachability, etc., to SCEF 100        2) SCEF 100 validates the monitoring event subscription request and sends a Diameter configuration information request (CIR) to HSS 104 over the s6t interface with a unique SCEF-Reference ID generated for the user.        3) HSS 104 sends a Diameter configure information answer (CIA) message to SCEF 100 with a success cause code.        4) SCEF 100 responds with an HTTP response 201 created message to SCS/AS 102.Reporting Phase:        1) When monitoring data is available for the UE on HSS 104, HSS 104 will send a Diameter reporting information request (RIR) to SCEF 100.        2) SCEF 100 validates the request and notifies SCS/AS 102 with a monitoring status notification message carrying the monitoring information.        3) SCS/AS 102 sends a success T8 response cause code back to SCEF 100.        4) SCEF 100 indicates a successful subscription to HSS 104 in a Diameter reporting information answer (RIA) message.        
FIG. 2 illustrates the monitoring event procedure through the HSS when the HSS does not have the requested information. Referring to FIG. 2, when HSS 104 does not have the requested UE status information, HSS 104 contacts MME 106 for the information. The configuration phase in FIG. 2 may include the following steps:
Configuration Phase:
                1) SCS/AS 100 sends a monitoring subscription request containing the monitoring event, such as location info, UE reachability, etc., to SCEF 100        2) SCEF 100 validates the monitoring event request and sends a Diameter CIR message to HSS 104 over the S6t interface with a unique SCEF-Reference ID generated for the user.        3) HSS 104 sends a Diameter insert subscription data request (IDR) to an MME 106 requesting the monitoring information for the identified user.        4) MME 106 accepts the monitoring request and returns an insert subscription data answer (IDA) to HSS 106 with a success cause code.        5) HSS 104 sends a Diameter CIA message to SCEF 100 with a success cause code.        6) SCS/AS 102 receives the monitoring subscription response from SCEF 100 with a 201 created HTTP response code.The reporting phase in FIG. 2 may include the following steps:Reporting Phase:        1) When monitoring data is available for a UE on MME 106, MME 106 will send a Diameter RIR to SCEF 100 over the t6a interface with the same SCEF-Reference id generated for the user during the configuration phase.        2) SCEF 100 validates the reporting information request and notifies SCS/AS 102 with a monitoring status notification message carrying the monitoring information.        3) SCS/AS 102 sends a success T8 response cause code to SCEF 100.        4) SCEF 100 sends a Diameter success to MME 106 in an RIA message.        
A procedure separate from the 3GPP monitoring event procedure is used to monitor LWM2M devices. This procedure or protocol is referred to as the LWM2M protocol and uses constrained application protocol (CoAP) as transport. The LWM2M protocol does not involve the SCEF. Instead, an IoT AS is required to implement LWM2M and CoAP procedures to communicate with IoT devices directly (through a packet gateway or serving gateway). The LWM2M protocol is used for device communication and management between IoT devices and the SCS/AS.
According to the LWM2M protocol, an information reporting interface is used by an LWM2M server to observe any changes in a resource on a registered LWM2M client, receiving notifications when new values are available. This observation relationship is initiated by sending an observe or observe-composite operation to the LWM2M client for an object, an object instance, or a resource. An observation ends when a cancel observation or cancel observation-composite operation is performed.
As stated above, the CoAP is used as transport for LWM2M messages. The CoAP is a specialized web transfer protocol for use with constrained nodes, such as IoT devices and constrained (e.g., low-power, lossy) networks. The protocol is designed for machine-to-machine (M2M) applications, such as smart energy and building automation. CoAP messages are very small and hence limit the need for fragmentation of messages in the network. The CoAP protocol enables CoAP clients to observe resources, i.e., to retrieve a representation of a resource (IoT device status) and keep this representation updated by the server over a period of time.
FIG. 3 is a diagram illustrating the use of the LWM2M protocol and CoAP to observe sensor data for a defined duration. In FIG. 3, an LWM2M client 300 is an IoT device. An LWM2M server 302 is an SCS/AS. More precisely, the SCS/AS is required to implement LWM2M and CoAP procedures to obtain state information from the IoT device. In FIG. 3, LWM2M server 302 makes an observation for a required resource (e.g., temperature) that is updated inside LWM2M client 300 at irregular periods (based on change) using a CoAP request message (GET method) carrying Observe Option=0. Notifications are sent by the IoT device (LWM2M client 300) in reply to the single extended GET request that created the registration (subscription). Each notification includes the token specified by the SCS/AS in the observation request. Notifications typically have a 2.05 (Content) response code. The notifications include an observe option with a sequence number for reordering detection.
When LWM2M client 300 receives a reset in response to a notify operation, LWM2M client 300 must cancel the observation regardless of whether the notify was sent as a confirmable CoAP message as defined in the observe operation or as a non-confirmable CoAP message. LWM2M server 302 can also cancel the observe operation at any time, on a specified resource, resource instance or specified object instance(s), by sending a GET request with observe option=1. LWM2M server 302 may optionally set the observe attributes of a Resource to affect the behavior of its notifications using the write-attributes operation implemented using a CoAP PUT request.
One problem with using the above-described procedures for different types of IoT devices is that the SCS/AS will be required to implement two separate northbound interfaces to monitor the IoT device status:                the 3GPP defined T8 monitoring event interface; and        the LWM2M server implementation to observe the resource state of an IoT device using the CoAP protocol interface. There is no unified SCS/AS interface for monitoring IoT device state or intelligence in the SCS/AS for identifying the type of IoT device and protocol for monitoring IoT device state using the correct protocol. The network operator can perform authentication, authorization, and access control of SCS/AS northbound traffic only for 3GPP-based T8 interface traffic at the SCEF but cannot enforce the same for LWM2M CoAP traffic going directly through an over the top communication method (i.e., using the data plane through a packet gateway).        
Accordingly, there exists a need for improved methods, systems, and computer readable media for monitoring IoT device state using a unified interface provided by the SCEF for LWM2M and non-LWM2M IoT devices.